Subject: re:Proposal for APPN Class of Service

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 1 Aug 1995 12:08:00 -0400

In message "Proposal for APPN Class of Service", Gary Dudley writes:

>When a subnet offers multiple service levels (such as priority or delay
>sensitivity as Jim suggests), the TG characteristics should be defined
>in a manner that suggests the real trade offs that route selection must
>make.  For example, a high priority service offers less delay but at
>higher cost than a lower priority service.  Likewise, I believe a
>delay-sensitive service would offer similar cost and delay trade offs
>relative to a satellite service.  I'm not sure how delay and cost compare
>between a high-priority satellite circuit and a low-priority delay-sensitive
>circuit, but the following TG characteristics illustrate the idea.
>
>            lowpri/sat  lowpri/delsen   hipri/sat   hipri/delsen
>Cost/byte       64           128           144         192
>Delay           99            91            81          71

Gary is right to point out that low delay circuits will generally have higher
tariffs/costs than high delay circuits.  Therefore his sugestion to reflect
the network delay characteristic in the Cost/Byte column as well as in the
network delay column is reasonable.

However Gary's Delay row does not match the real behavior of a network.
Most particularly no amount of priority is going to make a packet cover a
satellite hop in 36 milliseconds (the meaning of Delay=0x81).  It is also
important to recognize that in the real world priority does NOT typically
have much effect to reduce average delay.  Priority only affects average
delay on congested trunks, and few networks are designed so that they are
normally congested.

What high priority typically DOES buy is not LOW delay, but rather CONSISTENT
delay.  Note that delay variance IS one of the explicit QoS characteristics
in ATM.  However it is NOT one of the TG characteristics recognized by APPN.
The reason that a network administrator prefers a high priority VC
for interactive traffic is because of the predictability of response time,
which is a consequence of the low variance in network delay of a high
priority virtual circuit.

That is why the Delay characteristic line in the above must be:

 Delay           99            91            99          91
					     **          **

As far as the COS table goes, Gary is right to point out that the customer
does not really want to prefer high cost circuits for interactive traffic.
However cost per byte is much less significant with interactive traffic than
with batch.  If there were some other way to prefer high priority virtual
circuits than through the Cost/Byte row, then I would propose that the
interactive COS entries should have cost/byte ranges of 0 to 255.  However
there does not appear to be any current TG characteristic which is
demonstrably better on a high priority VC than a low priority VC.  Therefore
I stand by my contention that the COS entries for interactive and system
management should be modified to request high cost/byte VCs when looking at
TGs with packet delay or worse.

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Northern Telecom.     |

---

From: Dave Finnie <[email-masked]>
Date: Wed, 2 Aug 1995 09:19:06 +1000

> priority virtual circuit.

Excellent point, Jim. Studies have shown that what is more important
to an end user (interactive traffic) is variance in delay, rather than
the average delay. Humans can quite easily live with consistently long
(within reason) or consistently short delays, but apparently what
really gets their nickers in a twist is when it is too variable. The
reason I mention this is that the transport mechanism (APPN) needs to
model solutions that fit the requirements (stating the obvious, I
know).

While Gary has done an excellent job in trying to accomodate Jim's
requirements without changing what we have today, I agree with Jim
that it doesn't quite fit.

Dave